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REMARKS 

Claims 1-7 are currently pending in the application. The Specification has been 
amended in response to the Examiner's objections as follows: change the reference 
number 60 to 50 at page 10, line 25; change the reference number 61 to 51 at page 10, 
line 27; change the reference number 62 to 52 at page 10, line 29; change the reference 
number 63 to 53 at page 1 1, line 2; and change the reference number 64 to 54 at page 11, 
line 3. No new matter has been added. 

The Claimed Invention 
The claimed invention involves a system and a process for managing business, 
technical and operational data that uses a single interface in a shared space environment 
over the Internet, including a common authentication and environment. A supplier portal 
creates a central repository for the registration process, information, company 
information, and user information, making this information available to all applications 
that open into the supplier portal. In response to a request received from a supplier 
(guest) coordinator 101, a userid/password 102 is obtained, which is then supplied to the 
business representative 103. An application coordinator requests to create company and 
provide information to the portal administrator at 104. This information includes the 
company name, application, and supplier coordinator name, userlD, e-mail, etc. A 
determination is made in decision block 105 as to whether the supplier is registered. If 
the supplier is not registered, then a company profile is created in function block 106. If 
the supplier is registered, than a further determination is made in decision block 107 as to 
whether the application is registered. If the application is not registered, then a company 
and its mapping is created in function block 108 and, in function block 109, the supplier 
coordinator is registered and authorized to use the application. If the application is 
registered as determined in decision block 107, then a further determination is made in 
decision block 1 10 as to whether the application is mapped to the supplier and supplier 
coordinator. If the application is not mapped to the supplier and supplier coordinator, the 
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supplier coordinator mapping to the application is crated in function block 111. Finally, 
an e-mail not is sent to the supplier coordinator application administrator in function 
block 112. 

Claims 1-7 have been rejected under 35 U.S.C. § 102(e) as anticipated by U.S. 
Patent No. 6,606,606 to Starr. Applicants traverse on the basis that the rejection is 
ultimately based on the unsupported finding that an integrated financial transaction 
method, as in Starr, is equivalent to a process, or a data processing method, for managing 
business, technical and operational data as claimed by Claims 1-7. Applicants 
respectfully traverse on the basis that the Examiner's implicit findings in this regard 
constitute impermissible hindsight as well as an improper assertion of technical fact in an 
area of esoteric technology without support by citation of any reference work. See 
M.P.E.P. § 2144.03, citing In reAhlert, 424 F.2d 1088, 1091, 165 USPQ 418, 422-21 
(CCPA 1970). 

In addition, an integrated financial transaction method, as disclosed and claimed 
by Starr, cannot be employed without significant alteration as a process, or a data 
processing method, for managing business, technical and operational data, as claimed by 
the claimed invention. Even if it were hypothetically possible to convert an integrated 
financial transaction method for managing business, technical and operational data, such 
hypothetical conversion would make the method unsuitable for financial transactions 
according to the method disclosed and taught by Starr. Accordingly, Applicants 
respectfully traverse on the basis that any hypothetical conversion of the method of Starr 
to for managing business, technical and operational data would make the method 
disclosed and taught by Starr "inoperable for its intended purpose." In re Gordon, 221 
U.S.P.Q. 1125, 1127 (Fed. Cir.1984). 

Applicants further traverse the Examiner's rejection of Claims 1-7 for the reasons 
discussed below. 
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Claims 1 and 7 

Independent Claims 1 and 7, which have been rejected as anticipated by Starr, 
claim a supplier portal which, among other things, handles account setup in a manner 
patentably distinct from what is disclosed and taught by Starr. For example, where the 
supplier portal of Claims 1 and 7 deals with registration at the user level (Claim 1, 
lines 4-6; see also Claim 7, lines 4-5), the invention disclosed of Starr does registration at 
a subscriber level. (Starr, column 10, lines 13-21, cited in the Office Action at 3) In 
addition, the invention disclosed by Starr deals solely with financial transactions 
operations such as bill payment, payroll services, bank account management, among 
others. (Starr, column 10, line 47 - column 11, line 11, cited in the Office Action at 3) 
The claimed supplier portal, by contrast, allows generic registration and entitlement 
functions for any industry. (Claim 1, lines 17-19; see also Claim 7, lines 17-19) 
Furthermore, the claimed supplier portal provides approval notifications by actual e-mails 
sent to prospective approvers. Each such notification e-mail contains a link to the 
pending request to enable an approver to review the request in detail. (Claim 1, 
lines 20-22; see also Claim 7, lines 20-22) Starr does not have any concept of an 
approval process beyond actions taken on the server itself. And hence, no concepts of 
e-mails relating to an approval process either. (Starr, column 1 1, lines 12-35, cited in the 
Office Action at 3) 

Claims 1 and 7 have been rejected on the basis that the Examiner incorrectly 
found the limitation have been rejected on the basis inter alia that the Examiner 
incorrectly found the limitation "providing a supplier portal from which new guests 
indicate, using a Graphical User Interface (GUI) of the supplier portal Web page, whether 
they are a registered user or not" (Claim 1, lines 4-6; see also Claim 7, lines 4-5) to be 
anticipated by the following passage from the disclosure of Starr: 

FIG. 5 shows in more detail the types of operations that a subscriber 12 
would employ for initiating an account with the server 14 and for accessing and 
operating the application platform provided by server 14. Specifically FIG. 5 
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illustrates that a session between the subscriber 12 and the server 14 begins with a 
log on wherein the system determines whether or not the subscriber 12 logging on 
to the system is a new user, or a user that has already registered and therefor has 
an account. 

(Starr, column 10, lines 13-21, cited in the Office Action at 3) Conspicuously, the cited 
portion of Starr does not teach "providing a supplier portal from which new guests 
indicate, using a Graphical User Interface (GUI) of the supplier portal Web page, whether 
they are a registered user or not" as in Claim 1 as well as Claim 7. Equally 
conspicuously, Claims 1 and 7 do not claim a "subscriber," a "server," an "application 
platform," an "account," "initiating an account with the server 14," "accessing and 
operating the application platform provided by server 14," or "a session between the 
subscriber 12 and the server 14 begins with a log on wherein the system determines 
whether or not the subscriber 12 logging on to the system is a new user, or a user that has 
already registered and therefor has an account" as taught by the cited portion of the 
disclosure of Starr. 

Claims 1 and 7 have also been rejected on the basis that the Examiner incorrectly 
found the limitation "determining whether a guest is a registered user from input by the 
guest, and if not a registered user, prompting the guest to select 'Register' to link to guest 
registration (GR) where they can obtain a Web userid/password that enables them to 
register for any of global procurement applications available under the supplier portal" 
(Claim 1, lines 7-10; see also Claim 7, lines 6-9) to be anticipated by the following 
passage from the disclosure of Starr: 

If the server 14 determines that a user is a new user, the web server 40 generates a 
HTML page that directs the subscriber 12 to enter information about the 
subscriber 12 for enrolling the subscriber into the system. For example, the web 
server 40 can generate an HTML page that asks for a user name, credit card 
number, identification of the type of small business being operated by the 
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subscriber 12, such as a corporate business partnership, sole proprietorship, or 
trust. 

(Starr, column 10, lines 21-28, cited in the Office Action at 3) The cited portion of the 
disclosure of Starr does not teach "guest," "registered user," "prompting the guest to 
select 'Register,'" "guest registration (GR)," "Web userid/password," "global 
procurement applications," or "supplier portal" as in Claim 1 as well as Claim 7. In 
addition, Claims 1 and 7 do not claim a "server," a "user," a "new user," a "web server," 
an "HTML page that asks for user name, credit card number, identification of the type of 
small business being operated," "subscriber," or "corporate business partnership, sole 
proprietorship, or trust" as in the cited portion of the disclosure of Starr. 

Claims 1 and 7 have further been rejected on the basis that the Examiner 
incorrectly found the limitation "when a guest obtains a Web userlD/password in GR, 
storing guest information in a GR data store" (Claim 1, lines 11-12; see also Claim 7, 
lines 10-1 1) to be anticipated by the following passage from the disclosure of Starr: 

Once the server 14 has received the completed form from the subscriber 12, the 

server 14 can open an account for the subscriber. 
(Starr, column 10, lines 28-30) The cited portion of the disclosure of Starr does not teach 
"guest," "Web userid/password in GR," or "storing guest information in a GR store" as in 
Claim 1 as well as Claim 7. In addition, Claims 1 and 7 do not claim a "server," "receive 
the completed form from the subscriber," or "can open an account for the subscriber" as 
in the cited portion of the disclosure of Starr. 

Claims 1 and 7 have been rejected on the basis that the Examiner incorrectly 
found the limitation "determining whether any applications have been authorized for a 
registered guest and, if not, prompting the guest to register for restricted applications in a 
portal common registration (PCR) where information is stored in a PCR data store 
throughout an application's approval cycle" (Claim 1, lines 13-16; see also Claim 7, lines 
14-16) to be anticipated by the following passage from the disclosure of Starr: 
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Once the account is open, the web server 40 may present to the subscriber 12 an 
HTML page that provides the subscriber 12 with a series of optional financial 
transactions that the subscriber 12 can activate and direct the server 14 to perform. 
For example, as shown by FIG. 5 the server 14 can present to the subscriber 12 an 
HTML page that includes graphical control elements which allow the subscriber 
12 to instruct the application server to implement functions related to the 
subscriber's core account, a bill paying operation, access controls, download 
functions, or flash reports. For example, the subscriber 12 may select to view and 
perform transactions in the core account. The core account is or can be a cash 
management account which combines check writing and debit card services while 
providing true money market rates of return on all balances. Cash for all business 
needs such as paying checks or submitting the payrolls can be electronically 
debited from the core account. 
(Starr, column 10, lines 30-47, cited in the Office Action at 3) The cited portion of Stan- 
does not teach "determining whether any applications have been authorized for a 
registered guest," "if not, prompting the guest to register for restricted applications," "a 
portal common registration (PGR) where information is stored in a PCR data store," or an 
"application's approval cycle" as in Claim 1 as well as Claim 7. In addition, Claims 1 and 
7 do not claim "[OJnce the account is open, the web server 40 may present to the 
subscriber 12 an HTML page," "provides the subscriber 12 with a series of optional 
financial transactions that the subscriber 12 can activate and direct the server 14 to 
perform," "server 14 can present to the subscriber 12 an HTML page," "graphical control 
elements which allow the subscriber 12 to instruct the application server to implement 
functions related to the subscriber's core account, a bill paying operation, access controls, 
download functions, or flash reports," "subscriber 12 may select to view and perform 
transactions in the core account," "core account is or can be a cash management account 
which combines check writing and debit card services while providing true money market 
rates of return on all balances," or "cash for all business needs such as paying checks or 
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submitting the payrolls can be electronically debited from the core account" as taught in 
the cited portion of the disclosure of Starr. 

Claims 1 and 7 have been rejected on the basis that the Examiner incorrectly 
found the limitation "accessing information from the GR data store to automatically build 
a customized home page for the guest, this home page being modified and updated as the 
guest's requests for access to applications get approved" (Claim 1, lines 17-19; see also 
Claim 7, lines 17-19) to be anticipated by the following passage from the disclosure of 
Starr: 

The set up, execution, and ongoing management of all financial transactions can 
be maintained under the control of the subscriber 12 through accessing and 
controlling the core account through the server 14. 

The bill paying operation can be a bill paying procedure implemented by 
the server 14 that lets the subscriber 12 pay vendors electronically. The system 
provides ease of use and can track and consolidate the information regarding bill 
paying right into an account statement. Payments can include remittance 
information to enable proper crediting of the subscriber 12's accounts with 
vendors. Additionally, the server 14 can provide an account payroll function. The 
account payroll service will enable the subscriber 12 to set up and submit payroll 
information electronically. The subscriber 12 can then perform all standard 
payroll functions electronically from wherever the subscriber 12 chooses to log in, 
, and at any time the subscriber 12 chooses to log in to the application server. 

Additionally, the server 14 allows the subscriber 12 to download 
information. Specifically, the server 14 allows the subscriber 12 to link the 
account with an accounting software package maintained by the subscriber 12, for 
example, at the PC workstation that the subscriber 12 is employing for accessing 
the server 14. The data can be downloaded to a file on a PC which can then be 
imported to an accounting package, such as Quicken, or any small business 
accounting package. Optionally, the server 14 may provide other financial 
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transaction controls such as controls for implementing retirement plans, small 
business lending, business credit card management, prepaid telephone services, or 
any other suitable financial transactions. 
(Starr, column 10, line 47 - column 11, line 1 1, cited in the Office Action at 3) The cited 
portion of Starr does not teach "accessing information from the GR data store," 
"automatically build a customized home page for the guest," or a "home page being 
modified and updated as the guest's requests for access to applications get approved" as in 
Claim 1 as well as Claim 7. In addition, Claims 1 and 7 do not claim "[t]he set up, 
execution, and ongoing management of all financial transactions . . . maintained under the 
control of the subscriber 12 through accessing and controlling the core account through 
the server 14, "[t]he bill paying operation can be a bill paying procedure implemented by 
the server 14 that lets the subscriber 12 pay vendors electronically," "[t]he system 
provides ease of use and can track and consolidate the information regarding bill paying 
right into an account statement," "[p]ayments can include remittance information to 
enable proper crediting of the subscriber 12's accounts with vendors," "the server 14 can 
provide an account payroll function," "[t]he account payroll service will enable the 
subscriber 12 to set up and submit payroll information electronically,""[t]he subscriber 12 
can . . . perform all standard payroll functions electronically from wherever the subscriber 
12 chooses to log in, and at any time the subscriber 12 chooses to log in to the application 
server," "server 14 allows the subscriber 12 to download information," "server 14 allows 
the subscriber 12 to link the account with an accounting software package maintained by 
the subscriber 12, for example, at the PC workstation that the subscriber 12 is employing 
for accessing the server 14," "data can be downloaded to a file on a PC which can then be 
imported to an accounting package, such as Quicken, or any small business accounting 
package," or "server 14 may provide other financial transaction controls such as controls 
for implementing retirement plans, small business lending, business credit card 
management, prepaid telephone services, or any other suitable financial transactions" as 
taught by the cited portion of the disclosure of Starr. 
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Claims 1 and 7 have been rejected on the basis that the Examiner incorrectly 
found the limitation "determining whether approval is needed for a requested application 
and, if so, sending a request for approval to the application administrator and receiving a 
response from the application administrator" (Claim 1, lines 20-22; see also Claim 7, 
lines 20-22) to be anticipated by the following passage from the disclosure of Starr: 

Turning to FIG. 6, one example of the operation of the server 14 can be 
seen. As shown by FIG. 6, a process 70 is illustrated wherein the server 14 in step 
72 receives the instructions from the subscriber 12 through the form or through a 
control activated by the client on the web page provided to the subscriber 12. In 
one example, the subscriber 12 instructs the server 14 to make payroll. Once the 
instruction is received by the server 14, the server 14 may in step 74 check an 
access control. The access control is part of the application server's ability to 
provide multiple access to a small business owner's accounts by allowing multiple 
users to share the account. For example, the application server 14 may allow a 
proprietary user, such as the root user, to set up a plurality of accounts, such as an 
account for their accountants, CFO or secretary. The small business owner can 
provide controls that set the access the other user is given. For example, the 
accountant can be given the control necessary to prepare bills for being paid 
electronically, however, can lack the necessary level of access to be able to 
actually kick off electronic payment. Optionally, other access controls can be set 
up to provide some users with view only control of monies in certain accounts. 
(Starr, column 11, lines 12-35, cited in the Office Action at 3) The cited portion of Stan- 
does not teach "determining whether approval is needed for a requested application" or 
"if so, sending a request for approval to the application administrator and receiving a 
response from the application administrator" as in Claims 1 and 7. In addition, Claims 1 
and 7 do not claim "a process 70 is illustrated wherein the server 14 in step 72 receives 
the instructions from the subscriber 12 through the form or through a control activated by 
the client on the web page provided to the subscriber 12 " "subscriber 12 instructs the 
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server 14 to make payroll," "[o]nce the instruction is received by the server 14, the server 
14 may in step 74 check an access control," "[t]he access control is part of the application 
server's ability to provide multiple access to a small business owner's accounts by 
allowing multiple users to share the account, "the application server 14 may allow a 
proprietary user, such as the root user, to set up a plurality of accounts, such as an account 
for their accountants, CFO or secretary," "[t]he small business owner can provide 
controls that set the access the other user is given," "the accountant can be given the 
control necessary to prepare bills for being paid electronically . . . [but] can lack the 
necessary level of access to be able to actually kick off electronic payment," or "other 
access controls can be set up to provide some users with view only control of monies in 
certain accounts" as in the cited portion of the disclosure of Starr. 

Finally, Claims 1 and 7 have been rejected on the basis that the Examiner 
incorrectly found the limitation "storing links to all applications for which the guest is 
approved, these links being reflected in the personalized supplier portal home page which 
displays a list of links to all of the applications for which the guest has been registered 
and authorized" (Claim 1, lines 23-25; see also Claim 7, lines 23-25) to be anticipated by 
the following passage from the disclosure of Starr: 

Thus, it can be understood that the systems and methods described herein, 
including those depicted in FIGS. 1-4 provide an individual or entity with an 
integrated tool kit for managing a plurality of financial service products. It will 
further be understood that these systems allow a subscriber to access the server 14 
remotely, such as through the Internet, and that the subscriber 12 may enter a 
single user name and one ID or password and thereby gain access to the 
application server running on the platform 14. 
(Starr, column 10, lines 4-12, cited in the Office Action at 4) The cited portion of Stan- 
does not teach "storing links to all applications for which the guest is approved" or "links 
being reflected in the personalized supplier portal home page which displays a list of 
links to all of the applications for which the guest has been registered and authorized" as 
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in Claim 1 as well as Claim 7. In addition, Claims 1 and 7 do not claim "provide an 
individual or entity with an integrated tool kit for managing a plurality of financial service 
products," "systems allow a subscriber to access the server 14 remotely, such as through 
the Internet," or "subscriber 12 may enter a single user name and one ID or password and 
thereby gain access to the application server running on the platform 14" as in the cited 
portion of the disclosure of Starr. 

For those reasons, Applicants respectfully submit that Claims 1 and 7 are not 
anticipated by Starr. 

Claim 2 

Dependent Claim 2, which has been rejected as anticipated by Starr, claims a 
supplier portal which, among other things, handles account setup in a manner patentably 
distinct from what is disclosed and taught by Starr. For example, Starr does not have any 
approval cycle, let alone an n-level approval cycle as in Claim 2. (Claim 2, lines 3-4) In 
addition, the supplier portal of Claim 2 allows enrollment to applications hosted in the 
Internet with as many userids and passwords as needed. A user may have one userid and 
password in one realm but a different userid and password for applications hosted in other 

realms. (Claim 2, lines - ) Starr does not appear to teach the concept of realms but 

instead appears to require use of a single userid and password for all accessible services. 
The absence of any discussion in the disclosure of Starr of the concept of realm or of 
applications hosted in multiple realms may be explained by the fact that the financial 
services with which Starr is concerned do not require the application of such concepts. 
(Starr, column 8, lines 37-65, cited in the Office Action at 4) The supplier portal of 
Claim 2, however, does require application of concepts of realm and of applications 
hosted in multiple realms because the supplier portal manages registration and 
entitlement for applications that are completely separate from the supplier portal itself. 
Because Claim 2 depends from Claim 1, the foregoing discussion of Claim 1 is 
incorporated by reference. 
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Claim 2 has been rejected on the basis that inter alia the Examiner incorrectly 
found the limitation "defining 1 to n level approval cycles a user must go through to get 
authorized to access an application" (Claim 2, lines 3-4) to be anticipated by the 
following passage from the disclosure of Starr: 

The instruction generator 44 employs the information stored within a 
database 16 to generate instructions for the financial service provider 28. To this 
end, the instruction generator 44 can access data stored within the database 16 
which is representative of a login data for accessing an on-line financial service 
provided by the financial service provider 28. The login of can include a telephone 
number, user account identifier, password, or any other information necessary for 
the server 14 to act as the subscriber's proxy in accessing the online financial 
services provided by the financial service provider 28. 
(Starr, column 9, lines 20-30, cited in the Office Action at 4) The cited portion of Stan- 
does not teach "defining 1 to n level approval cycles a user must go through to get 
authorized to access an application" as in Claim 2. In addition, Claim 2 does not claim 
"[t]he instruction generator 44 employs the information stored within a database 16 to 
generate instructions for the financial service provider 28," "the instruction generator 44 
can access data stored within the database 16 which is representative of a login data for 
accessing an on-line financial service provided by the financial service provider 28," or 
"[t]he login of [sic] can include a telephone number, user account identifier, password, or 
any other information necessary for the server 14 to act as the subscriber's proxy in 
accessing the online financial services provided by the financial service provider 28" as in 
the cited portion of the disclosure of Starr. 

Claim 2 has also been rejected on the basis that the Examiner incorrectly found 
the limitation "logging in by a registered guest by inputting the guest's usereid/password 
once for each session, as long as applications requested by the guest are in a same realm" 
(Claim 2, lines 5-6) to be anticipated by the following passage from the disclosure of 
Starr: 
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For example, an [sic] continuing with the earlier described example, the 
subscriber 12 can employ a web browser to access the web server 40 component 
of the server 14 and to receive from the server 14 an HTML, XML, SGML or 
other suitable format document that can act as the user interface 32. In one 
example, the user interface 32 is an HTML page that employs the FORM 
tag/protocol for allowing a subscriber to transmit data to the server 14. For 
example, the user interface 32 can provide the subscriber 12 with a form that 
allows the subscriber 12 to enter a customer identifier and a password. The 
subscriber 12 submits the data to the server 14 and, as discussed above, the server 
14 processes the data to determine whether the subscriber 12 is an authorized user 
and optionally the level of access to be granted to the subscriber 12. 

Once the server 14 determines that the subscriber 12 can have access to an 
account maintained by the server 14 and can determine the level of access for the 
subscriber 12, the server 14 can update the user interface 32, by providing to the 
subscriber 12 a page, such as an HTML page, that presents to the subscriber 12 
one or more user controls, typically button controls, that allow the subscriber 12 to 
direct the server 14 to perform an integrated financial transaction. For example, 
one button can provide the subscriber with a control that allows the subscriber 12 
to direct the server 14 to perform a payroll operation for the company. Upon 
activating the control, the browser can deliver to the server 14, information 
representative of an instruction to make payroll. 
(Starr, column 8, lines 37-65, cited in the Office Action at 4) The cited portion of Stan- 
does not teach "logging in by a registered guest by inputting the guest's usereid/password 
once for each session, as long as applications requested by the guest are in a same realm" 
as in Claim 2. In addition, Claim 2 does not claim "the subscriber 12 can employ a web 
browser to access the web server 40 component of the server 14 and to receive from the 
server 14 an HTML, XML, SGML or other suitable format document that can act as the 
user interface 32," "the user interface 32 is an HTML page that employs the FORM 
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tag/protocol for allowing a subscriber to transmit data to the server 14," "the user 
interface 32 can provide the subscriber 12 with a form that allows the subscriber 12 to 
enter a customer identifier and a password," "[t]he subscriber 12 submits the data to the 
server 14 and, as discussed above, the server 14 processes the data to determine whether 
the subscriber 12 is an authorized user and optionally the level of access to be granted to 
the subscriber 12," "the server 14 determines that the subscriber 12 can have access to an 
account maintained by the server 14 and can determine the level of access for the 
subscriber 12," "the server 14 can update the user interface 32, by providing to the 
subscriber 12 a page, such as an HTML page, that presents to the subscriber 12 one or 
more user controls, typically button controls, that allow the subscriber 12 to direct the 
server 14 to perform an integrated financial transaction," "one button can provide the 
subscriber with a control that allows the subscriber 12 to direct the server 14 to perform a 
payroll operation for the company," or "[u]pon activating the control, the browser can 
deliver to the server 14, information representative of an instruction to make payroll" as 
in the cited portion of the disclosure of Starr. 

Finally, Claim 2 has been rejected on the basis that the Examiner incorrectly 
found the limitation "invoking by a logged in guest any of their approved applications by 
simply clicking the link to the desired application in the guest ? s customized home page" 
(Claim 2, lines 7-8) to be anticipated by the following passage from the disclosure of 
Starr: 

For example, upon logging onto the system, the web server 40 may present to the 
subscriber an HTML page that includes a number of controls each of which 
correspond to an available integrated financial transaction which the subscriber 
can activate. 

(Starr, column 8, lines 21-25, cited in the Office Action at 4) The cited portion of Starr 
does not teach "invoking by a logged in guest any of their approved applications by 
simply clicking the link to the desired application in the guest's customized home page" 
as in Claim 2. In addition, Claim 2 does not claim "upon logging onto the system, the 
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web server 40 may present to the subscriber an HTML page that includes a number of 
controls each of which correspond to an available integrated financial transaction which 
the subscriber can activate" as in the cited portion of the disclosure of Starr. 

For those reasons, Applicants respectfully submit that Claim 2 is not anticipated 
by Starr. 

Claim 3 

Dependent Claim 3 has been rejected as anticipated by Starr, even though Stan- 
does not disclose or teach a concept of an approval cycle, let alone a customizable 
approval cycle for each application. (Claim 3, line 2) Because Claim 3 depends from 
Claims 1 and 2, the foregoing discussion of Claims 1 and 2 is incorporated by reference. 

Claim 3 has been rejected on the basis that the Examiner incorrectly found the 
limitation "wherein the approval cycles are customizable for each application" (Claim 3, 
line 2) to be anticipated by the following passage from the disclosure of Starr: 

The login of [sic] can include a telephone number, user account identifier, 
password, or any other information necessary for the server 14 to act as the 
subscriber's proxy in accessing the online financial services provided by the 
financial service provider 28. 
(Starr, column 9, lines 26-30, cited in the Office Action at 4) The cited portion of Starr 
does not teach "wherein the approval cycles are customizable for each application" as in 
Claim 3. In addition, Claim 3 does not claim "[t]he login of [sic] can include a telephone 
number, user account identifier, password, or any other information necessary for the 
server 14 to act as the subscriber's proxy in accessing the online financial services 
provided by the financial service provider 28" as in the cited portion of the disclosure of 
Starr. 

For those reasons, Applicants respectfully submit that Claim 3 is not anticipated 
by Starr. 
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Claim 4 

Dependent Claim 4 has been rejected as anticipated by Starr, even though Starr 
does not disclose or teach a concept of an approval cycle, let alone an approval cycle 
defined for a section of an application, providing a finer level of access control. (Claim 4, 
lines 2-3) Because Claim 4 depends from Claims 1 and 2, the foregoing discussion of 
Claims 1 and 2 is incorporated by reference. 

Claim 4 has been rejected on the basis that the Examiner incorrectly found the 
limitation "wherein the approval cycles are defined for a section of an application, 
providing a finer level of access control" (Claim 4, lines 2-3) to be anticipated by the 
following passage from the disclosure of Starr: 

To this end, the instruction generator 44 can access data stored within the database 

16 which is representative of a login data for accessing an on-line financial service 

provided by the financial service provider 28. 
(Starr, column 9, lines 22-26, cited in the Office Action at 4) The cited portion of Starr 
does not teach "wherein the approval cycles are defined for a section of an application, 
providing a finer level of access control" as in Claim 4. In addition, Claim 4 does not 
claim "the instruction generator 44 can access data stored within the database 16 which is 
representative of a login data for accessing an on-line financial service provided by the 
financial service provider 28" as in the cited portion of the disclosure of Starr. 

For those reasons, Applicants respectfully submit that Claim 4 is not anticipated 
by Starr. 

Claim 5 

Dependent Claim 5 has been rejected as anticipated by Starr, even though Stan- 
does not disclose or teach application specific registration fields (Claim 5, lines 2-4). In 
Starr, during enrollment for a specific service, fields that are presented to a user are the 
same and pre-defined. (Starr, column 8, lines 37-51, cited in the Office Action at 4) But 
in the case of supplier portal of Claim 5, an unlimited number of fields may be configured 
real-time for any given application and presented to users during registration. Because 
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Claim 5 depends from Claims 1 and 2, the foregoing discussion of Claims 1 and 2 is 
incorporated by reference. 

Claim 5 has been rejected on the basis that the Examiner incorrectly found the 
limitation "wherein application specific registration fields are defined so that a 
registration form, unique to an application, is displayed when a user requests access to an 
application" (Claim 5, lines 2-4) to be anticipated by the following passage from the 
disclosure of Starr: 

For example, an [sic] continuing with the earlier described example, the 
subscriber 12 can employ a web browser to access the web server 40 component 
of the server 14 and to receive from the server 14 an HTML, XML, SGML or 
other suitable format document that can act as the user interface 32. In one 
example, the user interface 32 is an HTML page that employs the FORM 
tag/protocol for allowing a subscriber to transmit data to the server 14. For 
example, the user interface 32 can provide the subscriber 12 with a form that 
allows the subscriber 12 to enter a customer identifier and a password. The 
subscriber 12 submits the data to the server 14 and, as discussed above, the server 
14 processes the data to determine whether the subscriber 12 is an authorized user 
and optionally the level of access to be granted to the subscriber 12. 
(Starr, column 8, lines 37-51, cited in the Office Action at 4) The cited portion of Stan- 
does not teach "wherein application specific registration fields are defined so that a 
registration form, unique to an application, is displayed when a user requests access to an 
application" as in Claim 5. In addition, Claim 5 does not claim "the subscriber 12 can 
employ a web browser to access the web server 40 component of the server 14 and to 
receive from the server 14 an HTML, XML, SGML or other suitable format document 
that can act as the user interface 32," "the user interface 32 is an HTML page that 
employs the FORM tag/protocol for allowing a subscriber to transmit data to the server 
14," "the user interface 32 can provide the subscriber 12 with a form that allows the 
subscriber 12 to enter a customer identifier and a password," or "[t]he subscriber 12 
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submits the data to the server 14 and, as discussed above, the server 14 processes the data 
to determine whether the subscriber 12 is an authorized user and optionally the level of 
access to be granted to the subscriber 12" as in the cited portion of the disclosure of Starr. 

For those reasons, Applicants respectfully submit that Claim 5 is not anticipated 
by Starr. 

Claim 6 

Dependent Claim 6 has been rejected as anticipated by Starr, even though Stan- 
does not disclose or teach the limitations of Claim 6. Because Claim 6 depends from 
Claims 1 and 2, the foregoing discussion of Claims 1 and 2 is incorporated by reference. 

Claim 6 has been rejected on the basis that the Examiner incorrectly found the 
limitation "wherein guests may bookmark applications for later access, further 
comprising the step of prompting by an application a guest to enter their userid/password 
for authentication against data stored in the GR data store when the application is 
accessed using a bookmark." (Claim 6, lines 2-5) to be anticipated by the disclosure of 
Starr, even though Starr does not disclose or teach a comparable concept: 

[T]he Examiner believes it to be inherent that guests may bookmark applications 
for later access (because web interfaces can be bookmarked), further comprising 
the step of prompting by an application a guest to enter their userid/password for 
authentication against data stored in the GR data store when the application is 
accessed using a bookmark (when a site is bookmarked that requires 
authentication, future accesses to the site will require re-authentication). 
(Office Action at 5) The Examiner thus admits that no portion of Starr can be cited 
which teaches "wherein guests may bookmark applications for later access, further 
comprising the step of prompting by an application a guest to enter their userid/password 
for authentication against data stored in the GR data store when the application is 
accessed using a bookmark" as in Claim 6. Applicants respectfully traverse on the basis 
that the Examiner's finding that it is "inherent" constitutes impermissible hindsight as 
well as an improper assertion of technical fact in an area of esoteric technology without 
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support by citation of any reference work. See M.P.E.P. § 2144.03, citing In re Ahlert, 
424 F.2d 1088, 1091, 165 USPQ 418, 422-21 (CCPA 1970). 

For those reasons, Applicants respectfully submit that Claim 6 is not anticipated 
by Starr. 

Conclusion 

In view of the foregoing, it is respectfully requested that the application be 
reconsidered, that Claims 1-7 be allowed, and that the application be passed to issue. In 
the alternative, it is requested that this amendment be entered for purpose of appeal. 

Should the Examiner find the application to be other than in condition for 
allowance, the Examiner is requested to contact the undersigned at the local telephone 
number listed below to discuss any other changes deemed necessary in a telephonic or 
personal interview. 

A provisional petition is hereby made for any extension of time necessary for the 
continued pendency during the life of this application. Please charge any fees for such 
provisional petition and any deficiencies in fees and credit any overpayment of fees to 
Deposit Account No. 09-0458 (IBM-Fishkill). 

Respectfully submitted, 

Michael E. Whitham 
Registration No. 32,635 

Whitham, Curtis & Christofferson, P.C. 
1 1491 Sunset Hills Road, Suite 340 
Reston, VA 20190 
703-787-9400 
703-787-7557 (fax) 



